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(54) Ole for design and modeling 

(57) A method for manipulating a first three-dimen- 
sional object, in a computer system including a display, 
a first software application, and a second software 
application. The present method includes the step of 
creating a model of the first three-dimensional object 
with the first software application, which has a first 
three-dimensional coordinate system A step of storing 
the model of the first three-dimensional object in a 
model formal is also included. The present method fur 
ther includes the step retrieving the model of the first 
three-dimensional object in the model format into a sec- 
ond software application, the second software applica- 
tion having a second coordinate system. The present 
method also includes the step of manipulating a view of 
the model of the first three-dimensional object with the 
second software application and within the second 
coordinate system. 
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Description 

The present invention relates generally to the area of computer-aided design and computer-aided manufacturing 
(CAD/CAM) software, and more specifically to methods for enabling the transfer of three-dimensional data between 
s CAD/CAM software applications. 

Object Unking and Embedding (OLE 1 ) Overview 

Within the oflice environment, one method that has been developed to enable "cutting" and "pasting" of data 
ib between software applications is "object linking and embedding (OLE). OLE defines standardized interfaces and func- 
tions enabling users to transfer "objects" between software applications. The following seclion is an abbreviated over- 
view of some of she concepts used in OLE version 2.0. irom Microsoft Corporation of Belleview. Washington, and 
defines some ot the terms that will be used in the disclosure. Further information and details about OLE may be 
obtained from "Inside OLE 2" by Kraig BrocKschrnidt. 1994. Microsoft Press, hereby incorporated by reference. 
is An example of cutting and pasting data between software applications is illustrated in Fig. l . Fig. 1 illustrates a two- 

dimensional object f created in a first software application being transferred into a second software application. The first 
and second software applications (not shown) are commonly specialized software applications such as spread-sheets, 
word processors, or graphics programs. Once two-dimensional object 1 has been transferred, the second software 
application can manipulate its own data, two-dimensionat object 2. so that two-dimensional object 2 interacts with two- 
Si) dimensional object 1 . The resulting document is then output to the user. 

OLE provides a set of "interfaces", or groups of functions, which when combined provide the mechanics enabling 
the user to transfer data between programs. Fig 2 illustrates the convention tor representing an OLE interface 10. for 
an object 1 1 and a "consumer" 1 2 of the object. Object 1 1 is said to have an "interface implementation", including inter- 
faces 1 3 and 14, lhai are analogous to an object oriented programming "class." Interfaces 1 3 and 1 4 include member 
25 functions 1 5 and 16, respectively, that are analogous to object oriented programming class "instances". 

Consumer 12 receives data from object 1 1 by calling functions of interface 13 and/or interface 14. In some cases 
the consumer may only be aware of one of several interfaces available in an object. In response to the function calls, 
objed 10 may return specific data about itself to the consumer 12. Object 10. however maintains exclusive control of its 
own data 1 7. As further illustrated in Fig. 2, (Unknown is an interface available to all object, thai when queried for spe- 
30 crfic interfaces, returns pointers to the requested interface. For example, assuming consumer 1 2 knows which functions 
are available in interface 13. consumer 12 can ask for and receive a pointer to interface 14. Then, once consumer 12 
receives a pointer to interlace 1 4. consumer 12 can call member functions 16 

The functions provided in the currently available OLE standardize the transfer of placement and size information, 
of objects between software applications. Two type of "transferring" objects from a first software application to a second 
35 software application include "linking" and "embedding", 

"Linking" an object that is created in a first software application to a second software application is when the object 
maintains its existence separate from the second software application, although the second software application can 
use" and reference She object. Unking also allows the user to modify and edit the object with the first software applica- 
tion without having to invoke the second software application. 
40 "Embedding" a first data objed into a second software application is when the object is actually integrated with the 

data stored and used by the second software application. Embedding allows the user to modify and edit the object only 
after lirst invoking the second software application. 

"Linking" an object is commonly preferred when the linked object includes a large quantity of data. One drawback 
to linking however, includes maintaining and remembering the particular path or directory of the linked object in the 
45 computer memory. "Embedding" an object is commonly preferred when the positioning and relationship of the embed- 
ded object to Other data within the second software application is important to maintain. One drawback to embedding 
however, includes that the embedded object cannot be edited or modified by the user without invoking the second soft- 
ware application. 

Two other commonly used OLE terms are "servers' and "containers". As illustrated in Fig. 2, the data 1 7 actually is 
SO only a portion of the object 10. The functions 15 and 16 serve to manipulate data 17 and to convey this data to the con- 
sumer 12. Because object 10 "serves" and manages the data, it is often called a "server". A "container" is defined as 
the user of the information contained within the server. In Fig. 2, the container is consumer 12. In a macroscopic scale, 
in the example in Fig. l , the server is the first software application which manages object 1 , and the container is the 
second software application. A container may access multiple servers, one for each object within the container's "envi- 
55 ronment" and further, containers and servers may be nested. 

The lerm "In Place Activation" is another important term in OLE. "In Place" activation enables a first software appli- 
cation to be active within a second software application. As illustrated in Fig. 1, an object 1 created in a spreadsheet 
application is inserted into a document 2 created by a word processing application. Without In Place activation capabil- 
ity, once object 1 is inserted into document 2, if the user wishes to revise the entries in object 1 , normally the user would 



2 



EP 0 723 250 A2 



have to quit the word processing application, enter the spreadsheet application, revise object 1, reinvoke the word 
processing program and then transfer the revised object 1. This indirect manner of editing transferred object occurs 
because the software application receiving the object only recognizes the object as a two-dimensional black box. With 
In Place activation, the user can directly invoke the spread sheet application from within the word processing applica- 
nt tion. OLE provides the interface capability for the two software applications so they can communicate with each other. 
As a result, the user can revise object 1 using the spreadsheet application without quitting the word processor applica- 

OLE version 2.0 is currently available with Microsoft Corporation's Windows™ operating system version 3.1. Cur- 
rently many office environment software applications such as Microsoft Corporation's Excel and Word support OLE 

io standards and interfaces. As was illustrated in Fig. 1 . object 1 . created in a first software application such as a spread 
sheel. is transferred into a second software application such as a word processor. Among other variables passed 
between the software applications, the second software application needs to know the two-dimensional sire of the 
object 1 so that it can make room for it in trie document. The second software application obtains the two-dimensional 
size of first data object f by calling and relying on OLE functions. Based upon the two-dimensional size, the second soft- 

is ware application can modify ils own data, object 2. to 'wrap around" object 1 . 

OLE is not limited to two-dimensional objects and is also used to incorporate and transfer audio and video data 
between software applications. Currenf OLE functions work well with office environment data objects, i.e., two dimen- 
sional objects that are defined by a two-dimensional bounding boxes. OLE functions however, only allow the user toper- 
form rudimentary two-dimensional functions on the boxes such as resizing, locating, and rotating. 



Application software specifically designed for architectural and engineering purposes are commonly labeled Com- 
puter Aided Design (CAD) and Computer Aided Manufacturing (CAM) software. Some of the standard features of 
ps CAD/CAM applications is the ability to create and manipulate three-dimensional objects and to position three-dimen- 
sional objects relative to ofher three-dimensional objects. 

As itlustrafed in Fig. 3 a three-dimensional object in a CAD/CAM environment is typically represented as a two- 
dimensional image to the user in the form of a print-out or display. Examples of commonly displayed views of a three- 
dimensional object are a top, right-side, front, and isometric views. Fig 3 illustrates thai a top view, a right-side view. 
30 and a front view of three-dimensional object 20 are derived from orthogonal projections onto a top two-dimensional 
viewing plane 21. a right-side two-dimensional viewing plane 22. and a front two-dimensional viewing plane 23 espe 
tively. Fig. 3. also iliuslrates that an isometric view of three-dimensional object 20 is derived from projections onto iso- 
metric viewing plane 24. 

In the past. CAD/CAM software applications were tightly coupled to specialized computer hardware because of the 

35 heavy computational and-display demands of the software. Because of this specialization, these CAD^CAM worksta- 
tions werecomplete, self-contained working environments. Once the user used one vendor's workstations, there would 
be little possibility to use anolher vendor's workstations due to cost considerations. Because the user tended to stay 
with a particular vendor in the past, there was little need to transfer three-dimensional objects created in a first 
CAD/CAM application to a second CAD/CAM application. 

to With the increase in processing capabilities of personal computers, personal computers are now replacing the tra- 
ditional workstations of the design engineer. This shift in the CAD/CAM computing environment has lessened the ties 
of ihe user to a particular vendor and now allows the user to choose the CAD/CAM application that best suits the prob- 
lem or the user s preferences. In addition, with the increase in computing platforms, more than one engineer can now 
work on the same problem simultaneously. 

« Currently, C AO/CAM packages from different vendors rely upon proprietary data formats and do not allow the user 

to transfer objects created in one software application to another vendor's software application Thus although compu- 
ter hardware has become more advanced, the CAD/CAM software has not. What is needed are software functions and 
tools thaf enable the user to transfer data objects created by a first CAD/CAM software application into a second 
CAD/CAM software application. 

so Currently, if the user attempted to use the present two-dimensional functions of OLE and apply them in the area of 

CAD/CAM applications, the shape of a three-dimensional object would fail to be transferred. Fig. 4 illustrates a front 
view 30 of a first three-dimensional object created by a first software application and an isometric view 31 of a second 
three-dimensional object created by a second software application. Consistent with the OLE standard, front view 30 is 
defined by a bounding hox 3? having dimensions 33 and 34. When front view 30 is transferred to the second software 

55 application, the second software application merely sees two-dimensional bounding box 32 and has no understanding 
of how to integrate the two objects in three-dimensional space. Because office environment concepts of data objects 
are only two-dimensional objects that are defined by two-dimensional bounding boxes, OLE is ill suited for use in the 
field of CAD/CAM applications. Further, even if it were somehow possible to transfer the two-dimensional shape of a 
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first three-dimensional object into a second software application, OLE does not provide a mechanism for transferring 
depth information of an object. 

What is needed is a standardized method for allowing the user to transfer three-dimensional data between software 
applications. 

5 The present invention provides enhancements and extensions to OLE for the CAD/CAM environment thai allows 

the user to transfer an object created by a first software application to a second software application, while preserving 
the three-dimensional nature of the object. 

Fig. 1 iliusSrat.es a two-dimensional object 1 created in a first software application being transferred into a second 

10 software application: 

Fig. 2 illustrates the convention for representing an OLE interface, tor an object and a "consumer - of the object; 
Fig. 3 illustrates that a top view, a right-side view, and a front view of three-dimensional object are derived trom 
orthogonal projections onto a top two-dimensional viewing plane, a right-side two-dimensional viewing plane, and 
a front two-dimensional viewing plane, respectively; 

is Fig. 4 illustrates a front view of a first three-dimensional object created by a first software application and an iso- 

metric view of a second three-dimensional object created by a second software application; 
Fig. 5 illustrates that a first three-dimensional object is created with a first software application and a second three- 
dimensional object is created in a second software application; 

Fig. 6 illustrates the concept of transparency with a display oi a three-dimensional objed and a two-dimencional 
so object in a three dimensional coordinate system; 

Fig. 7 is a block diagram of a system according to a preferred embodiment of the present invention; 
Fig. 8 iltustrates the !Ole3bObject interface in a user interface o! an object. 

Fig. 9 is a flow diagram of one embodiment of the process of determining whether the object is a three-dimensional 
Object; 

ss Figs. 1 0a and 10b illustrate two different orientations of an object with regard to its own coordinate system and with 
regard to a containers coordinate system. 

Figs. 1 1a and 1 1b are flow diagrams of one embodiment of the process of determining the actual extent of a three- 
dimensional object within a container using Oe3DObject;:Get3DExtenl: 

Fig. 12 illustrates that a three-dimensional object 310 and a two-dimensional object are inserted into in a fhree- 
30 dimensional container, 

Fig. 13 is a flow diagram of one embodiment of the process of determining whether a two-dimensional container 
can retrieve a view of a three-dimensional object; 

Fig. 14 illustrates a flow diagram o! one embodiment of the process of a two-dimensional container calling GetDe- 
faultvlew to display a default view of a three-dimensional object; 
ss Fig. 15 illustrates a default view {the front view) of a three-cSmensional object is inserted into a two-dimensional 
container; 

Fig. 16 illustrates a flow diagram of one embodiment of the process of calling SetView to allow a two-dimensional 
container to set and display a view of a three-dimensional object: 

Fig. 1 7 illustrates a view of a three-dimensional object that is inserted in a two-dimensional container; 
io Fig. 1 8 illustrates the IViewGLObject interface for a user interface of an object; 

Fig. 19 is a flow diagram of one embodiment of the process of determining whether the object supports OpenGL 
COM; 

Fig. 20 is a flow diagram of one embodiment ol the process of having a server displaying the object by calling 
OpenGL COM functions; 
is Fig, 21 illustrates the !OlelnPiace3DObject interface for a user interface of an object; 

Rg. 22 is a flow diagram of one embodiment ol the process of determining whether the three-dimensional object 
supports In Place activation; 

Rg. 23 illustrates that the attachment matrix between the server's coordinate system and the container's coordinate 
system is initially calculated; 
se Rg. 24 illustrates a top view, a front view, and a right-side view of a three-dimensional object; 

Fg. 25 illustrates the tOleinPlaceSDSife interface for a user interface for a three-dimensional object; 

Fig. 26 is a flow diagram of one embodiment of the process of determining whether the three-dimensional object 

supports In Place activation: 

Fig. 27 illustrates an object is embedded into a first container andf irst container embedded into a second container: 
ss Fig. 28 illustrates the attachment matrix between the In Place active server's coordinate system and the immedi- 

ately adjacent container's coordinate system is initially calculated; 

Rg. 29 illustrates the lOlelnPlaceViews interface for a user interface for a three-dimensional object; 
Rg. 30 illustrates a iOlelnPiaceActive3DObject interface for a user interface: 
Fig. 31 illustrates the lOleLocate interface for a user interface of an object; 
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Fig. 32 is a flow diagram of one embodiment of the process of locating elements in an object using the PointLocate 
function: 

Ftg. 33 is a flow diagram of one embodiment of the process of locating elements in an object using the ShapeLo- 
cate function; 

£ Figs. 34a - 34c illustrate the use of the tOleLocate.:PointLocate function; and 

Fig. 35 is a flow diagram of one embodiment of the process ol in-place activating. 

One of the objectives of the following OLE extensions is to enable the user to transfer three-dimensional objects 
between software applications. An example of this is illustrated in Fig. 5. In Fig. 5 a first three-dimensional object 40 is 
w created with a first software application and a second three-dimensional object 41 is created in a second software appli- 
cation. Firs: three-dimensional object 40 includes top leg 42, bottom leg 43, and slot 44. When first three-dimensional 
object 50 is retrieved into the second software application, the second software application should be able lo resize, 
rotate, and manipulate the first three-dimensional object as one of its own. (However the second software application 
will still not be able to edit the object.) As illustrated in Fig. 5, first three-dimensional object 40 and second three-dimen- 
is sional object 41 are both rotated in the three-dimensional cooidinate system of the second software application and are 
assembled. The second software application should be able to recognize the three-dimensional nalure of rirst three- 
dimensional object 40, by allowing top leg 42 to obscure a portion of second three=dimensional object 41 and by allow- 
ing second three-dimensional object 41 to obscure a portion of bottom leg 43 

One specific result of the following OLE extensions is to enable three-dimensional Objects to have transparent 
so bounding boxes. Fig. 6 illustrates the concept of transparency with a display 50 of a three-dimensional object 51 and a 
two-dimensional object 52 in a three-dimensional coordinate system. Three-dimensional object 51 includes slot 54 and 
two -di mensiona! obj ect 52 tncl udes area 54 . 

The Current OLE enables the user to transier two-dimensional "black boxes" of information without regard to the 
contents of the box. If a first three-dimensional object is returned into the second software application, the second-soft- 
2s ware application should receive ihe actual shape of the three-dimensional object, and not obscure more of the image 
than necessary when transferred. As illustrated in Fig. 6. with the following OLE extensions the second software appli- 
cation recognizes that slot 53 allows the user to see through object 51. ie object 51 is transparent in slot 53, and thus 
the underlying two-dimensional object 52 remains visible in area 54. 

in sum, adding the following described extensions to OLE provides the following capability 1) enabling the commu- 
te nication between three-dimensional oojects, servers, and containers, as well as enabling communication between two- 
dimensional containers and three-dimensional objects and servers, and enabling communication between Ihree- 
din lynbional coi itamers and two-dimensional objects; 2) enabling three-dimensional servers to navigate within a two or 
three-dimensional container environment, including enabling multiple In Place active views; and 3) enabling three- 
dimensional objects to interact with other objects within the container environment. 
35 It is believed that one familiar with OLE, as described in "Inside OLE 2" by Kraig Brockschmidt, would be able to 

readity use the following OLE extensions based upon the following disclosure. Further details about the preferred 
method of enabling such transfer of data are detailed in the following sections. 

System Overview 

40 

Fig. 7 is a block diagram of a system 60 according to a preferred embodiment of the present invention. System 60 
includes a display monitor 61 . a computer 62, a keyboard 63, and a mouse 64. Computer 62 includes familiar computer 
components such as a processor 65, and memory storage devices such as a random access memory (BAM) 66. a disk 
drive 67, and a system bus 60 interconnecting the above components. Mouse 64 is but one example of a graphical input 

45 device, a digitizing tablet 65 is an example of another 

In a preferred embodiment, system 60 includes a IBM PC compatible personal computer, running Windows™ oper- 
ating system Version 3.1 and OLE 2.0 by Microsoft Corporation, and Avalon™ software, currently under development 
by Intergraph Corporation. The appendix includes preferred embodiments of the Avalon™ OLE extensions described 
below, written in Visual C++. The appendix also includes sample source code programs that incorporate the Avalon™ 

so OLE extensions. 

Fig. 7 is representative of but one type of system for embodying the present invention. If will be readily apparent to 
one of ordinary skill in the art that many system types and configurations are suitable lor use in conjunction with the 
present invention. 

55 Ihree-Dimensipnal Eaensipnsjo fiLE 
0. Type Definitions 

1 Interfaces Enabling Three-Dimensional Object Handling 
1 .1 . IOie3DObject interface 
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1.2. I ViewGLObject interface 

1.3. iOlelnPlace3D0bject interface 

2. Interfaces Enabling Navigation of A Container Environment 
2.1. fO!elnPlace3DSite interface 

s 2.2. OeinPlaceViews interface 

2.3. 10lelnPlaceActive3DObject interface 

3. Interfaces Enabling Three-Dimensional Object Interaction 
3.1. lOleLocate interface 



is Type Definitions 

The following are type definitions, described in the preferred embodiment in C++, used in the descriptions of the 
preferred embodiment of the formal OLE extension interfaces. 

tagDVREP is used to specify how the object is displayed to the user. 

typedef enum tagDVRSP { // standard representations 

DVREP_CONrEHT =1, // dioplay all the details of the 

object 

20 DV-REP_SIMPLIFIED = 2, // display a simplified version 

DVKEP_SxMBOL = 4, // dioplay as a symbol 

DVBEP_TEXT =8 // display only the text description 
} DVREP; 



EXTENT3D is a list of coordinates defining the range of the object in three-dimensions. 
/; Extent definition 

typedef doublQ* EXTENT3D; // Low point, and High pointo (6 

doubles) 

typedef EXTENTthuee-dimensional LPEXTENT3D; 



Clipping plane equations are a set of four points ir, space that define a plane, which in turn defines a boundary 
in space. 

40 // Clipping plane equations 

typedef double* CLlFPLANEEQUftTlON -, // 6 plane equations complying with GL 
format (24 doubles) 

typedef CL I P P LAKE EQU AT ION LPCLI PPLANES ; 



XFORM3D is a matrix used for conveying parameters to the three-dimensional rendering utility. 
// XForm matrix 



ss 
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typedef double" XFORM3D ; // Matrix of 16 doubles complying with 

CL format 

typedef XFORMthree-dimenaional LPXFORM3D; 



><? LM^ces En ^iinq Three-Dimensional Object Handling 

The new OLE interfaces as described herein allow containers and servers, both which manipulate three-dimen- 
sional oDjects. to lake advantage of the third dimension while maintaing backwards capability. Specifically, the new 
interlaces allow two-dimensional objects to be inserted into three-dimensional containers and three-dimensional 
ts objects into two dimensional containers. Manipulation of an object however, still does not add the capability Of editing a 
transferred object. 

Hereinafter, unless specified, the term "container" refers to a container that supports either two-dimensional or 
Ihree-dimensional objects, and the term "object" refers to a three-dimensional object or a two-dimensional object. 

so 1A IOIe3DObject Interface 

The !Ole3DObject interface is an extension of the existing OLE lOleObject interlace and allows a three-dimensional 
container to retrieve three-dimensional information about an object. JO!e3DObject functions are used in the same pro- 
gramming context as the OeObject funclions. with added functionality described below. The lOle3DOoject interface 
25 also allows a two-dimensional container that understands three-dimensions to specify and retrieve a view of a three- 
dimensional object. 

Fig, 8 illustrates the IOIe3DObject interface 70 in a user interface 72 of an object. User interface 72 includes an lUn- 
krown interface 74 that is available in all OLE objects, and an OeObject interlace 76 that is also available in all OLE 
objects. (Unknown interface 74 includes an interface inplementatton having a function 78, that when called returns a 
30 pointer to Oe3dObject interface 70 if the object is a three-dimensional object and a function 80, that when called 
returns a pointer 1o OeObject interface 76. OeObject interface 76 includes an implementation having a function 82 
that when called returns a pointer to IOIe3dObject interface 70 tt the object is a three-dimensional object. Oe3DObject 
interface 70 includes an implementation having (unctions 84, 86, 88, 90, and 92. which are described below. 

Fig. 9 is a flow diagram of one embodiment of the process of determining whether the object is a three-dimensional 
55 object. 

During initialization of an object, (e g , creating or loading an object) the container queries (Unknown function 78 for 
a pointer to IOie3DObject interface 70 (step 100). At the same time, the container queries fUnknown function 80 lor a 
pointer fD lOleObject interface 76 in case the object is not a three-dimensional object (step 110). 

In a preferred embodiment, the container further queries lOleObject function 82 for a pointer to IOle3D0bject inter- 
ns face 70. Once IOte3DObject interface 70 is located, the container queries IOIe3DObject function 84 and ensures there 
is a pointer to OeObject interface 76. 

If ths query of lOleObject function 32 or lUnknown function 78 return a NULL pointer (step 120). the object is not a 
three-dimensional object and the container must treat the object as a two-dimeitbional object (step 130). If the above 
queries return a pointer to IOie3DObject interface 70 Ihe container can treat the object as a three-dimensional object 
45 (Step 140). 

In practical terms, if a first software application creates a Ihree-dimensional object using the OLE IOIe3DObject 
interface extensions described herein, a second software application, will then be able to call !Ole3DObject functions to 
obtain three-dimensional data about the object. 
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The following is a description of the preferred embodiment of the formal IOIe3DObject interface: 

interface Iole3DOb ject : iunknown { 
// * TUnknown methods * // 

HRESULT Querylnterf ace (REFI3D riid, LPVOID FAR* ppvOb j ) ; 
TJLONGAddRef ( ) ; 
ULONGRelease < ) ; 

// * TOle3DObject methods * // 

HRESULT Oet3DExtent (DVEEP duRep, LPEXTENTthree- 

dimensional pExtent]; 

HRESULT GetDef aultview ( LPXFORMthree-diirienBional pVToW, 

LPXFORMthree-dimensional pWToV, WORD 
uPlaneCnt, LPCLI PPLANES pCLip) ; 

HRESULT SetView (LPXFORHthree-dimenoiona 1 pVToW, 

LPXFORHthree-dxmensional pWTov, WORD 
uPlaneCnt, LPCLIPPLAMES pclip) ; 

}; 



The first !0le3D0bject function Get3DExtent returns the "extents" (or range) of an object in three-dimensions in 
response to being called by a container. This function is roughly analogous to fhe current OLE function lOleOb- 
ject::GelExtent except a third dimension is included. An object that supports the IO!e3DObject interface musl also sup- 
port the SOieObjeci interface in order to be backwards compatible with two-dimensional containers. 

Before the Get3DExtent funciion is called, the container must first calculate an "attachment" matrix. An attachment 
matrix is a mapping between a three-dimensional object's system to the container's system, as illustrated in Figs. 10a 
and 10b. 

Figs. 10a and 10b illustrate two different orientations of an object 160 with regard to its own coordinate system 170 
and with regard to a container's coordinate system 180. As illustrated, the object 160 can be moved, rotated, and 
resized in three dimensions with respect to coordinate system 180. The size and orientation of object 160 relative to its 
own coordinate syslem 1 70 however remains constant. The container keeps track of the positioning and size o! object 
160 within its coordinate system 180 by calculating and maintaining an attachment matrix that maps coordinate system 
1 70 to coordinate system ISO. 

Figs. 1 1a and 1 lb are flow diagrams ol one embodiment of Ihe process of determining the actual extent of a three- 
dimensional Object within a container using IOle3DObject::Get30Extent 

In Fig. l la, for a container to calculate the actual size of an object within the container's coordinate system, an 
attachment matrix is first calculated (step 200). 

Once the attachment matrix is calculated, the container calls K}le3DObjeci::Get3DExtent (step 210). As just 
described with Figs. 10a and 10b, although a container manipulates the view of the object within the container's coor- 
dinate system, the object maintains its relationship to its own coordinate system. In response to the function call 
GetSDExtent, the server returns the extent, or range, of the object relative to its own coordinate system. 

Once the attachment matrix and the extent of the object have been determined, the container then calculates the 
extent of the object within the container's coordinate system (step 220), in the preferred embodiment by multiplying the 
attachment matrix to the extent values. 

In the situation where the object is two-dimensional and the container is three-dimensional, the extents of the object 
can still be calculated, as illustrated in Fig. 1 1 b. An attachment matrix is first calculated in step 240. 

Once this attachment matrix has been calculated, the container calls the standard OLE function IO!eObject::GetEx- 
tent {step 250). In response to this function call, the server returns the two-dimensional extent of the object relative to 
its own coordinate sysiem. Next, the container calculates the actual extent of the object within the container's coordi- 
nate system (step 260), in the preferred embodiment by multiplying the attachment matrix to the extent values. 

The implications of mapping a two-dimensional object into a three-dimensional container are illustrated in Fig. 12. 
In Fig. 12, a three-dimensional object 310 and a two-dimensional object 320 are inserted into in a three-dimensional 
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container. The original two-dimensional object 330 is also illustrated. Because a two-dimensional object is mapped into 
three-dimensional space, the object can be manipulated in three dimensions by the container and can interact with 
other objects such as three-dimensional object 310 

The following is a description of the preferred embodiment of the formal Gei3DExtent interface: 



IQle3DObject: :Get30Extent 

HRESUX.T I01e3DObjcot: ; Get3DExtent (DWORD dwRep, LPEXTENTthree- 

dimensional pExtent ) 
Returns the three-dimensional extent of a three-dimensxonal object, 
depending on its representation. 
Argument Type Description 

dwRep DVREP Type of representation requested. It is an extension o: 

the two-dimensional aspect of XOleObject: :GetExtent. 
This argument is a DVREP type. 
pExtent LPEXTEKT3D Array of 6 doubles representing the low and high 

points of the object expressed in the server 
coordinate oyotera. 
return value s OK The extent is returned succeasf ully . 

E_IHV7LLIDARG One of the arguments ig invalid. 

E^OUTOFMEMORY Out of memory. 

E_UNEXPECTED An unexpected error happened. 



The next iOle3DObject function GetDefaultView specifically provides a twoKfimensiona! container the ability to 
retrieve a predefined view of a three-dimensional object. As was illustrated in Fig. 3. a three<iimensional object is typ- 
ically viewed as a two-dimensional object on a viewing plane. One view such as front view 23. is further predefined as 
a default view. 

Fig. 13 is a flow diagram of one embodiment of the process of determining whether a two-dimensional container 
can retrieve a view ol a three-dimensional object 

If a two-dimensional contain3er does not support three-dimensional objects, i.e. is not aware of the IOIe30Object 
interface, the two-dimensional container queries lUnknown function 76 in Fig. 7 for a pointer to lOleObject interface 76 
(Steps 350 and 360). If the two-dimensional container supports three-dimensional objecls, the two-dimensional con- 
tainer queriess lUnknown tunction 73 for a pointer to IOIe3DObject interface 70 (steps 350 and 370), 

II the query of lUnknown function 78 returns a NULL pointer (step 380). the object is not a three-dimensional object 
and the container treats the object as a conventional two-dimensional object. When either the object is two-dimen- 
sional, or the container does not support a three-dimensional object, the container retrieves a conventional two-dimen- 
sional view of the Object (step 4390) fl the query in step 380 returns a pointer to lOleSDObject interface 70 the 
container treats the object as a three-dimensional object (step 400). 

Once the container determines it can support a three-dimensional object, the container retrieves a two-dimensional 
view of the object. 

Fig. 1 4 illustrates a flow diagram of one embodiment of the process of a two-dimensional container calling GetDe- 
faultView to display a default view of a three-dimensional object. 

Before the GetDefaultView function is called, the container must first calculate a "transformation" matrix between 
the server's three-dimensional coordinate system and the display's two-cimensional coordinate system Another term 
used for this matrix is a "server world to view" matrix, where the serves" world is the object's coordinate System and the 
"view" is the display's coordinate system. 

In Fig. 14, for a server to determine the dfsplay position of the default view of the ob;ect on the display the "trans- 
formation matrix" is first calculated (step 420). 

Once the transformation matrix is calculated, the container calls IOIe3DObject::GetDefaultView (step 430) and 
passes the transformation matrix to the server. Based upon the transformation matrix, the server displays a default view 
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of the object to the display (step 440). The actual process of a server displaying the object will be discussed later in this 
disclosure. 

The result of a two-dimensional container retrieving a default view of a three-dimensional object and displaying it is 
illustrated in Fig. 1 5. )n Fig. 1 5 a default view 460 {the front view) of a three-dimensional object 470 is inserted into a 
two-dimensional container. After the container retrieves the three-dimensional object and passes (he transformation 
matrix to the server, the server calculates and displays default view 460 to the display. The actual process of a server 
displaying the object will be discussed later in this disclosure. Because the container is also aware of the transtormation 
matrix and positioning of the object, as illustrated, the container can then manipulate its data 480 to interact with default 
view 460. 

The actual display position of the three-dimensional object in the container is governed by the variable IprcPosRect 
relumed by the function call OlelnPlaceSite:;GetWindowContext as described in "inside OLE 2' described above. 
The following is a description of the preferred embodiment of the format GelDefaultView interface; 

I01e3DObject : : GetDef aultView 

HREStJLT IOTe3DObject : :GetDef aultView (LPXFORM3D* ppVToW, LPXFORM3D* 

ppWToV, WORD" pwWaneCnt, 
LPCL.XPPLMiES-' ppClip) 

Returns the default view with which a server displays. 

Argument Type Description 

ppVToW LPXFORH3D* Matrix representing the View to Server World 

(pixel to tbrce-dimens ional (real world) 
coordinate system) Transformation Matrix. This 
matrix is a 4x4 matrix as described in OperiCL view 
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LPXFORM3D* 



return value 



E_INVAI,I D ARG 
E_0"TOFMEKORY 



It includes Rotation, Translation, 
, Perspective and shearing information. 
Matrix representing the Server World to View 
Transformation Matrix. This matrix is a 4x4 
matrix as described in OpenGL view matrices. It 
includes Rotation, Translation, Scale, Perspective 
and shearing information. This is the inverse of 
the pvtow argument without perspective or 
projections. 

WORD* Number of clipping planes used to display. This number 
can vary between 0 and 6. When the number is 0, the 
pointer to the clipping planes equations can be null. 

LPCLIPPLANES" Equations Of the clipping planes expressed 

into the Object coordinate system. Each 
clipping plane is represented by the 4 
coefficients of the plane equation. There 
is a maximum of 6 clipping planes; this is 
an array of 24 doubles. The defii 
the clipping planes is the same as : 
OpenGL. 

The display context is returned 
successfully. 

One of the arguments is invalid. 
Out of memory. 

An unexpected error happened. 



35 

1.1.3 iOle3D0biect::SetView 

The third I0le3D0bject lunciion specifically provides a two-dimensional container the ability to specify a view of the 
ao three-dimensional object. As is illustrated in Fig. 3. three-dimensional container must be view and displayed from a 
viewing plane. The present function allows a two-dimensional container to define that viewing plane. 

Fig. 16 illustrates a flow diagram of one embodiment of the process of calling SetView to allow a two-dimensional 
container to set and display a view of a three-dimensional object. 

In Fig. 16. for a server to determine the display position of the default view on a display, a transformation matrix {as 
45 described atxve) between the server's coordinate system and the display's coordinate is first calculated is first calcu- 
lated (step 490). 

Once the transformation matrix is calculated, the container calls tOle3DObject::SetView (step 500) and passes the 
transformation matrix to the server. Based upon the transformation matrix, the server displays a view of the object to 
the display (step 51 0). The actual process of a server displaying the object will be discussed later in this disclosure. 
53 The result of a two-dimensiona! container defining a view of a three-dimensional Object is illustrated in Fig. 17. In 

Fig. 17 a view 530 of a three-dimensional object is inserted in a two-dimensional container. After the container retrieves 
the three<fimensional object and passes the transformation matrix to the server, the server calculates and displays 
view 530 to the display. Because the container is also aware of the transformation matrix and positioning of the object, 
as illustrated, the container can then manipulate its data 540 to mteracl with view 530. 

55 
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The following is a description of the preferred embodiment of the formal SetView interface: 



IOLe3DObject: : SetView 
H RESULT IOleJDObject : 



Allows the container t 
Argument Type 

pVToW I,PXFORM3D 



pWtoV LPXFORM30 



pClip LPCLIPPLAflES 



E_INVAXXDARG 

E OUTOFMEMORY 

E UNEXPECTED 



: SetView { LPXFORMthree-dimeno ional pVToH, 

LPXPOHHthrce-diaensional pWToV, WORD 
wPlaneCnt, LPCLIPPLANES pClip) 
o specify the view with which a server displays. 
Description 

Matrix representing the View to Server World 
(pixel to three-dimensional (real world) 
coordinate system) Transformation Matrix. This 
matrix ia a 4x4 matrix as described in OpenGL view 
matrices. It includes Rotation, Translation, 
Scale, Perspective and Bhearing information. 
Matrix representing the Server World to View 
Transformation Matrix. This matrix is a 4x4 
matrix as described in OpenGL view matrices. It 
includes Rotation, Translation, Scale, Perspective 
and shearing information. This is the inverse of 
the pVtoW argument without perspective or 
projections . 

Number of clipping planes used to display. 
This number can vary between 0 and 6. When 
the number ia 0, the pointer to the clipping 
planes equationn can be null. 
Equations of the clipping planes expressed into 
the Object coordinate system. Each clipping plane 
is represented by the 4 coefficients of the plane 
equation. There is a maximum of 6 clipping 
planes; this is an array of 2 4 doubles. The 
definition of the clipping planes is the same ao 
in OpenGL. 

The operation is successful. 
One cf the arguments is invalid. 
Out of memory. 

An unexpected error happened. 



1.2, IViewGLObject 

The IViewGLObject interface is an extension of the existing OLE IViewObject and allows a three-dimensional 
server to render a view of the object using IGL interface routines. IViewGLObjeel functions are used in the same pro- 
gramming context as the IViewObject functions, with added functionality described below. The IGL interface. OpenGI 
COM. includes standardized three dimensional graphics rendering functions 

Fig. 18 illustrates the IViewGLObject interface 550 for a user interface 5S0 of an object. User interface 560 includes 
an lllnknown interface 570 that is available in all OLE objects, and an IViewObjecl interface 580 lhat is also available 
in all OLE objects. (Unknown interface 570 includes a function 590 that when called returns a pointer to iViewGLobject 
interface 550 if the three-dimensional object can support OpenGL COM rendering interfaces and a function 600 that 
when called returns a pointer to IViewObject interface 580. IViewObjecl interface 560 includes a function 610 that when 
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called returns a pointer to IViewGLObject interface 550 if the three-dimensional object can support OpenGL COM ren- 
dering and also includes a standard OLE Draw function 620. tView3DObject interface 550 includes a function 630 that 
when called returns a pointer to IViewObject interface 580. and includes a Draw function 640 as will be described below. 
Fig. 19 is a flow diagram of one embodiment of the process of determining whether the Object supports OpenGL 
5 COM. 

During initialization of an object, (e.g.. creating or loading an object) the container queries lUnkrtown function 590 
for a pointer to IViewGLObject interface 550 (step 660). At the same time, the container queries lUnknown function 600 
for a pointer to IViewObject interface 550 in case the object does not support OpenGL COM (step 670). 

In a preferred embodiment, the container further queries IViewObject function 500 for a pointer to IView3DObject 
io interface 550. Once IView3DObject interface 550 is located, the container queries IView3DObject function 620 and 
ensures there is a pointer to lOieObject interface 580. 

ff the query of IViewObject function 610 or lUnknown function 590 return a NULL pointer (step 680). the server 
does not support the OpenGL COM rendering and the object is displayed in the conventional manner provided by OLE 
(step 690). If the above queries return a pointer to IView3DObject interface 550 the server supports OpenGL COM (step 
is 700). 

The following is a description of the preferred embodiment of the formal IViewGLObject interface: 

interface IViewGLObject : lUnknown { 
so II * lUnknown methode- * // 

HRESULT Cuerylnterface (RSFIID riid, LPVOID FAR* ppvOb j ) ; 
ULONGAddRef (); 
ULONGRe lease { ) , 



// * IViewGLObject methods - // 

HRSSULT Draw (DWORD dwRep, LPIGL pIGL, LFXFORMthree-dimens ion&l 

pvrow, LPXFORMthree-dimensional pwtov, word 

wPlaneCnt, LPCL IP PLANES pClip); 



The use of the !ViewGLObject::Draw function is relative straightforward. Fig. 20 is a flow diagram of one embodi- 
ment of the process of having a server displaying the object by calling OpenGL COM functions. 

In Fig. 20, the transformation matrix between the container's coordinate system and the display (World 10 View) is 
4S calculated (step 720). Next, dipping plane equations that specify which portions of the object are rendered, are defined 
{step 730). Based upon the transformation matrix and the dipping plane equations, the server then calls IViewGLOb- 
ject:. 'Draw to render the object (step 740) 



••• 
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The following is a description of the preferred embodiment of the formal Draw inierface: 



IViewGLOb j ect ; : Draw 
HRESULT IViewGLObjectiiDraw 



DisplayB a server withi: 
Argument Type Description 
dwRep DVREP Type of representation request 

the two-dimensional aspect of 
This argument is a DVREP type. 



(DVREP dwRep, LPXGL pIGL, LPXFORMthree- 
diraensional pVToW, LPXFORHthree-dirnenBional 
pWToV, WORD «PlaneCnt, LPCLIPPLAHES * pClip) 
■play < 



ed- It is an extension of 
lOleObject; :CetExtent. 



pIGL 



LPIGI, 



pVToW LPXFORM3D 



pWtoV LPXFORM3D 



Pointer to the IGL interface. To display, the 
server simply calls IGL functions on the IGL 
interface pointer. 

Matrix representing the View to World (pixel to 
three-dimensional (real worlds) coordinate system) 
Transformation Matrix of the OuterMost In-Place 
container. This matrix is a 4x4 matrix as 
described in openGL view matrices. It includes 
Rotation, Translation, Scale, Perspective and 
shearing information- 
Matrix representing the World to View 
Transformation Matrix of the OuterMost In-Place 
container. This matrix is a 4x4 matrix ae 
described in OpenGL view matrices . It includes 
Rotation, Translation, Scale, Perspective and 
shearing information. If there is no perspective 
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or projections, this is the inverse of the pVtoW 
argument. 

wflaneCnt WORD Number o£ clipping planes used to display. 

This number can vary between 0 and 6. When 
the number Lb 0, the pointer to the clipping 
planes equations can be null. 
pClip LFCLIPPCANE5 Equations of the clipping planes expressed into 

the Object coordinate system. Each clipping plane 
is represented by the 4 coefficients of the plane 
equation. There is a maximum of 6 clipping 
planes; this is an array of 24 doubles. The 
definition of the clipping planes is the sajne as 
in OpcnGL. 

return value s _ OK Operation is successful. 

E__IN*VAIiIDfLRG One of the arguments is invalid. 

E__UNEXPECTED An unexpected error happened 



Note, the View to World and inverse: World to View matrices are both calculated. The World to View matrix is impor- 
tant to the server tor view independent displays, for example, when text within an object should not display sheared, 
related or skewed. 

1.3. IOIelnPlace3DObiect 

The J0!elnPlace3D0bject interface is used by three-dimensional container applications to negotiate the three- 
dimensional display context, especially during In Place activation of the se.'ver. 

Fig. 21 illustrates the !0lelnPlace300bject interface 760 for a user interface 770 of an object. User interface 770 
includes an lUnknown interface 780 that is available in alt OLE objects, and an lOlelnPlaceObject interface 790 that is 
also available in all OLE objects which can In Place activate. (Unknown interface 780 includes a function 800 that when 
called returns a pointer to iOlelnPlace3DObject interface 760 and a function 810 that when called returns a pointer to 
lOlelnPlaceObject interface 790. lOlelnPlaceObject interface 790 includes a function 820 that when called returns a 
pointer to IOleInPlace3DObject interface 760. lOlefnPlaceSDObject interface 760 includes a function 830 that when 
called returns a pointer to lOlelnPlaceObject interlace 790 and also includes a OnModelMatnxChange function 840 as 
will be described below. 

Fig. 22 is a flow diagram of one embodiment of the process of determining wheiher the three-dimensional object 
supports In Place activation. 

During initialisation of an object, (e.g.. creating or loading an object) the container queries lUnknown function 800 
for a pointer to l01elnPlace3DObjec! interface 760 <step 860). At the same time, the container queries lUnknown func- 
tion 81 0 for a pointer to lOlelnPlaceObject interface 790 in case the object is not a three-dimensional object {step 870). 

In a preferred embodiment the container further queries lOlelnPlaceObject function 820 for a pointer to 
!OielnPlace3DObject interface 760. 

If the query of lOlelnPlaceObject function 820 or lUnknown function 810 return a NULL pointer (step 880), the 
Object is not a three-dimensionaf object and the object is In Place activated using conventional OLE functions (step 
890). If the above queries return a pointer to IO!elnP!ace3DObject interface 760 the three-dimensional object can be In 
Place activated (step 900). 
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The following is a description of the preferred embodiment of the formal IOIe!nPtace3DObject interface: 

interface I01eInPlace3DObjoct : IUnknown { 
// * IUnknown methods * // 

H RESULT Querylntertace (RKFIID riid, LPVOID FAR* ppvobj ) ; 
ULOKCAddR«f ( ) ; 
TJLOMGSe lease ( ) ; 

// * IOleInPlace3DObject methods * // 

HRESULT OnModelMatrixChange ( LPXFORKtb.rec-diir.ens ional pMatrix); 



1 .3. 1 IOIe!npla ce3DObiect::QnMadelMatrixChanae 

so The OnModeiMatrix function provides the In Place active server with a new attachment matrix when the container 
modifies its coordinate system- 
Fig. 23 is a fbw diagram of one embodiment of the process ot using the IOlelnPlace3D0bjeci::On!v1cde1fv1atrix- 
Change function. In Fig, 23, the attachment matrix between the server's coordinate system and the container's coordi- 
nate system are initially calculated (step 920). Then, when the container's coordinate system is modified (step 930). the 

zs container calculates a modified attachment matrix between the server's coordinate system and the modified container 
coordinate system (step 940). The container then calls OnModelMatrixChange to notify the In Place Server of the mod- 
ified attachment matrix (step 950). With the modified attachment matrix, the In Place Server can then lake the modified 
attachment matrix, for example, and call IViewGLObject::Draw to draw an updated view of the object. 

The following is a description of the preferred embodiment of the formal OnModelMatrixChange interface: 

I01eInFlace3DObject : :OnModelMatrixChange 
HRESULT I01eIni>lace3DObject: : OnModelMatrixChange 

{LPXFORMthree-dimeneional pMatrix) 

35 



Notifies the in-place object that the outecmoot three-dimensional 
container changed its model transformation matrix. 



Argument 
pMatrix 



E_OUTOFMEMORy 
B_ I NVAL I D AUG 
E_UNEXPECTED 



Description 

Pointer to an array of 16 doubles representing the 
4x4 transformation from the in-place server to the 

matrix is ordered in the same way as a model 
transformation in OpenGL. It should not incLude 
any component that would make it singular (for 
example, perspective or projection). The matrix 
ifi allocated and deallocated by the caller. 
The notification is done successfully. 
The matrix cannot be allocated. 
The argument is invalid. 
An unexpected error happened 
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in the case where containers are nested within other containers, the attachment matrix is built-up by concatenating 
ail the attachment matrices from adjacent containers and servers. The resulting matrix is thus a mapping between the 
outermost three-dimensional container !o the in-plsce server. 

$ 2. Interfaces Enabling Navigation of A Container Environment 

The new OLE interface as described herein provides a transition for three-dimensional servers and containers that 
include large numbers of objects having complicated relationships. Particular features enabled by these OLE interlaces 
include objects having non-rectangular boundaries and having transparent regions. Another particular feature enabled 

jo by these OLE interfaces includes enabling a container to provide multiple views of an object, for example a top, right- 
side, and front view of an object, at ihe same time. These new OLE interfaces also allow objects to become simultane- 
ously in Pface active in the different views, for example the object can be edited in one view and the results carried over 
automatically to the other views of the object. 

Fig. 21 illustrates a top view 970, a front view 980, and a right-side view 990 of a three-dimensional object 1000. 

(5 When three-dimensional object 1000 is activated or retrieved, the server asks the container for positions in which the 
container supports In Place activation, for example positions 1010, 1020, and 1 030 In response to the container's posi- 
tions, the server creates a "child" view of the object corresponding to each of those positions. Each view is individually 
controlled in a manner similar to the standard OLE method of displaying a view of the object. In Fig. 24, the server dis- 
plays top view 970 in position 1010. front view 980 in position 1020. and right-side view 990 in position 1030 

so Because each view is simultaneously In Place active, each view allows the server to receive events such as mouse 
clicks. With standard OLE. when a mouse click, occurs outside the In Place active view, the view is deactivated and can- 
not receive input. With the OLE extensions, however, events occurring outside the In Place Active view is received by 
the server without the server bging deactivated. The default way to deactivate a server is with an (esc:, although the 
server can provide a menu selection or may interpret a double-click on another object as a signal become inactivate. 

25 The primary interface facilitating these functions is OlelnPlaceViews, to which ihe server obtains a pointer via 

iOIelnPlace3DSite::GetWindowContext. as will be described below. 



so The IOlelnPlace3DSite interface is an extension of the existing OLE lOlelnPlaceSite imerface and provides support 
for "In Place" activation of software applications creating three-dimensional objects. lOlelnPlaceSDSite lunctjons are 
used in the same programming context as the lOlelnPlaceSite functions, with added functionality described below. Spe 
ciiicaliy, the IOIe!nPiace3DSite interface allows servers to get the three-dimensional and view information from the con- 
tainer. 

ss Fig. 25 illustrates the IOIelnPlace3DSite interface 1050 for a user interface 1060 for a three-dimensional object. 
User interlace 1060 includes an lUnknown interface 1070 that is available in all OLE objects, and an lOlelnPlaceSite 
interface 1080 that is also available in all OLE objects which can In Place activate. lUnknown interlace 1070 includes a 
function 1090 that when called returns a pointer to l0felnPlace3DSite interface 1050 and a function 1 100 that when 
called returns a pointer to lOlelnPlaceSite interface 1080. lOlelnPlaceSite interface 1080 includesa function mo that 
40 when called returns a pointer to IOIelnPlace3DSite inleiace 1050. iOlelnPlace3DSite interface 1050 includes a Get- 
ModelMatrix function 1 120 and a GetWindowContext function 1 130 as will be described below. 

Fig. 26 is a flow diagram ot one embodiment of the process of determining whether the three-dimensional object 
supports In Place activation. 

During initiafeation of an object, {e.g., creating or loading an object) the container queries (Unknown function 1070 
-is for a pointer to 10lelnPlace3Dsite interface 1050 (slop 1 1 50). At the same time, the container queries lUnknown func- 
tion 1 100 for a pointer to lOlelnPlaceSite interface 1080 (step 1 160). 

In a preferred embodiment, the container further queries lOleinPiscesite function 1 1 10 to ensure there is a pointer 
to !OlelnPlace3DSite interface 1 050. 

If the Query of lOlelnPlaceSite function 1 1 10 or lUnknown function 1090 return a NULL pointer (step 1 170), the 
so three-dimensional object can not be In Place activated in more than one view (step 1 180). If the above queries return 
a pointer to lOlelnPlace3DSrfe interface 1050 the three-dimensional object can be In Place activated in multiple views 
(step 1190). 



55 
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The following is a description of the preferred embodiment of the formal IOlelnPlace3DSite interface: 

interface IOleInPlace3DSite : lUnknown { 
5 // * lUnkiiown methods * // 

HRESULT Quecylnterface (RSPXID riid, LPVOID PAR* ppvobj); 
TJLONGAddRef ( ) ; 

ULONGRelease { ) ; 
10 // * IOLeInPlace3DSite methods » // 

HREStTLT GetModelMatrix ( LPXPORHthree-dimeno Lonal pMatrix ) ; 

H RESULT GetWindowContext (LPOLEINFLACEVIEWS* ppInPlaceVLewa) ; 



ZAA.O 

The first 0!elnPiace3DSiie function GetModelMatrix aBows an embedded server to determine the attachment 
matrix between the server and the top-most container's coordinate system. Fig. 27 illustrates the general concept of 
embedding a server. In Fig. 27, an object 1210 is embedded into a first container 1220 and first container 1220 embed- 
ded into a second container 1230. fn order to facilitate positioning of object " 210 when the server is In Place active, an 
attachment matrix between the second container 1 230 to the object 1210 is calculated, bypassing firs; container 1;?20 

Fig. 28 is a flow diagram ot one embodiment of the IOIelnPlace3Dsi1e::GetModetMafri>; function. In Fig. 28. the 
attachment matrix between the In Place active server's coordinate system and the immediately adjacent container's 
coordinate system is initially calculated (step 1250). The server then determines whether the immediately adjacent con- 
tainer was the top most container (step 1 260). If. not the attachment matrix between the immediately adjacent container 
and the preceding container is calculated and appended to the attachment matrix (step 1270). Steps 1260 and 1270 
are repealed until an attachment matrix between the top most container and the server is calculated This attachment 
matrix is then passed to the server (step 1280). 

The following is a description of the preferred embodiment of the formal GetModelMatrix interface: 

301eInPlace3DSite: :GetKodelMatrix 
HRESULT IO!eInPlace3DSite: : GetModelMatrix 

(LPXFORMthrGf»-dimenaional pMatrix) 
Oeto the transformation matrix from the outermost three-dimensional 
container to the in-place server. 
Argument Type Description 



LPXFORM3D 



return, value 
E_UNEXP£CTED 



pointer to an array of 16 doubles 
representing the 4x4 transformation from the 
in-place server to the outermost three- 
dimensional container. This matrix is 
ordered in the same way as a model 
transformation in OpenGL. The matrix is 
allocated and deallocated by the caller. 
The matrix is returned successfully. 
An unexpected error happened. 
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This function is called by she in-place server and recurses until it reaches the outermost three-dimensional container, 
concatenating the matrices. 

2.1.2. QlelnPlace30 Site:: Qet WindowContext 

The second OielnPlace3Dsile function Get WindowContext provides an interface between the outermost container 
and the In Place Server. As was illustrated in Fig. 27 object T210 may be embedded into first container 1 220 and first 
container 1220 embedded into second container 1230. Because the object can be embedded within several layers of 
containers, upon In Place activation of the server, the server and the top most container need to communicate with each 
Other in order to pass system events This interface is partially accomplished by passing a pointer to the lOleln- 
Placeviews interlace of the outermost container to the object. The pointer to lOlelnPlaceViews derives from the function 
GstWtndowContext. lOlelnPlaceViews interface will be described below. 

The following is description of the preferred emt>odiment of the formal GetWindowContext interface: 

I01eTnPlace3DSite: :GetWindowContext 

HRESULT IOLeInPlace3D£ite GetWindowContext 

(LFOI.EIHPLACEVIEWS* ppInPlaceViews ) 
Returns the outermost three-dimensional container window context. 
Argument Type Description 

ppIn-PlaceViewo LPOLEINPLACEVIEWS- Pointer to the lOlelnPlaceViews 

interface of the outermost 
three-dimensional container.. 

return value S_OK The context is returned 

successfully. 

E_IKVALIDARC One of the arguments is invalid 

^ UNEXPECTED An unexpected error happened. 



This function recurses until it reaches the outermost three-dimensional container and returns its lOlelnPfaceViews 
interface to the in-p!ace server. This function establishes the handshaking between the outermost three-dimensional 
ss container and the three-dimensional in-place server. 

2.2. OeinPiaceViews 

The OelnPiace Views interlace is derived from tfie IOIeinPlace3DSite::GetWrndowContexi function (described 
40 above) and provides support for "In Place" activation of software applications that create three-dimensional objects. 
lOlelnPtaceViews functions are used in the same programming context as the lOtelnPlaceUIWindow functions, with 
added functionality described below. More specifically, lOlelnPlaceViews allows servers to obtain view information from 
the three-dimensional containers, such as the location and size of views 1010, 1020, and 1030, in Fig 24. 

Fig. 29 illustrates the lOlelnPlaceViews interface 1300 for a user interface 1310 for a three-dimensional oOject. 
45 User interface 1 3 10 also includes a lOlelnPlaceUIWindow interface 1320 thai allows In Place active objects to negotiate 
border space. lOlelnPlaceUIWindow includes function 1330. lOlelnPlaceViews interface 1300 includes a Enu- 
rnln Place Views function 1340, a GetViewContext function 1350, and a SetActive3DObject function 13S0 as will be 
described below. 
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The following is a description of the preferred embodiment of the formal lOielnPlaceViews interface: 

interface lOlelnPlaceViewe : lUnicnown { 
// * Itlnltnown methods « // 

HRESULT Querylnterface (REFIID riid r LPVOID FAR* ppvOb j ) ; 
ULONGAddRef (); 
ULONGRelease ( ) ; 

// * lOielnPlaceViews methods * // 

HRESULT EnumlnPlaceViewo { LPENUMHWND * ppenumHwnd) j 

HRESULT GetViGwContext {HWND riwnd, LPIGL* pIGL, LPXFORMthree- 

dinnangional pVToW, LPXFORMthree-dimensi< 

pWToV) ; 

HRESULT SetActive3DObjec ( LPOLErNPLft.C3ACTIVE3DOB.TECT 

p3DActiveObj) ; 

}; 



2.2.1 iOlelnPlaceViews ::E numlnPlaceVie ws 

The first lOielnPlaceViews function EnumlnPlaceVieA's a:lov/£ the ssrvgr to receive a list of the container's vsew i; 
which the server is in Place Activated. For example, in Fig. 24. views 1010. 1020. and 1030 would be enumerated a 
supporting In Place activation of the server. 

The following is a description of the preferred embodiment of the formal EnumlnPlaceViews interface: 

lOielnPlaceViews : : EnumlnP laceViews 
HRESULT lOielnPlaceViews: : EnumlnPlaceViews 

(LPENUMHWND* ppenumHwnd) 
Returns the list of in-place active windows into the container. 



Argument Type 

ppenumHwnd LPENUMHWND * Enumerator 

return value S_OK 

E_OUTOFMEMORY 
E^INVALIDARC 
E UNEXPECTED 



Description 
of the views used for in-place 

The Display context information is 
passed successfully. 

The enumerator cannot be allocated- 
One o£ the arguments is invalid 
An unexpected error happened. 



This function, implemented by three dimensional graphic containers, is called by In-Place three-dimensional servers to 
know the list of views concerned by in-piace aciivation. Once the object has this list, it can ack for their context by calling 
lOielnPlaceViews: :GetViewConiext. 

55 

2.2,2, ICIelnPlaceVi ews: :Get Vi ew Context 

The second lOielnPlaceViews function GetVi ewContext allows the server to obtain a transformation matrix 
between the top most container coordinate system and the display {i.e., world to view matrix). With this transformation 
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matrix for each of the In Place active views, the server knows the proper display context on the display, knows how to 
property process events such as mouse clicks on the display, and knows how to perform dynamic (rubberbandsng) dis- 
plays on that view, To avoid marshalling (defined in "Inside OLE 2" described above), a server could display itself by 
using 1he attachment matrix and World to View matrix to determine the context for the server view. 
i The following is a description of the preferred embodiment of 1he formal GetViewContext interface: 

IOlelnPlaeeViewa : : GetViewContext 
HRESULT IOlelnPlaeeViewa: : GetViewContext 
w (HWND hwnd, LPIGL* pIGL, LPXFORMtb.re»e- 

diraensional pVToW, LPXFORMthree-dimensional 
pWToV) 

Returns the Graphic context of the three-dimensional In-place Window, 
's Argument Type Description 

hwnd HWND Handle to the window to get the context from. 

pIGL LPIGL* Pointer to the IGL interface (Interface Graphic 

Library}, the server is responsible to add a 
80 reference, to this interface, and release it when 

it deactivates. 

pVToH LPXFORM3D Hatrix representing the View to World (pixel to three- 
dimensional {real worlds) coordinate system) 
25 Transformation Hatrix of the OuterMost In-Plaee 

container. This matrix is a 4x4 matrix as described in 
OpenGL view matrices. It includes Rotation, 
Translation, Scale, Perspective and shearing 



pWtoV LPXFORM3D 



return value 

E_OUTOFMEMORl 
E_INVALIDARG 
E UNEXPECTF. D 



Matrix representing the World to View Transformation 
Matrix of the OuterMost In-Place container. This matri; 
is a 4x4 matrix as described in OpenGL view matrices. 
It includes Rotation, Translation, Scale, Perspective 
and shearing information. This is the inverse of the 
pVtow argument without perspective or projections. 
S_OK The Display context information iB passed 
successfully. 

The matrix cannot oe allocated. 
One of the arguments is invalid 
An unexpected error happened. 



This function, implemented by three-dimensional graphic containers, is caiied by !n-Place three-dimensional servers to 
initialize their display context. The pointer to the IGL interface is different here. The server must push the container' s 
model matrix (see IO!etnPlace3DSite: GetModelMatrix) and the pWtoV matrix before displaying in dynamics. After dis- 
playing, the server should pop the context back. This allows the container (possibly upon an lAdviseS- 
ink:.-OnViewChange) to send the display to other objects without concern for this object' s display context. 
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2, : 2 J. ; I Q l e i nP l aceV iws;:S a M i yeai3Q^ 

The third OelnPlaceViews function SetActive3DObject allows She server to give the container a pointer to its 
IOie!nPlaceAclive3DObject interface, so that the container can modify 1he views, as will be described below. 
The following is a description of the preferred embodiment of the forma! SetActive3DObject interface: 

lOlelnPlaceviews : : SetAct ive3DOb ject 
HRESULT IClelnPlaceViews: : SetActive3DOb ject 

( LPOLEINPLACEACTI VE3DOBJECT p3DACtiveOb j ) 
Sets the I01eInPlaceActive3DOb ject connection. 
Argument Type Description 

p3DActiveOb3 LPOLEINPLACEACTIVE3DOBJECT 

Pointer to the IGlelnAct i veOh j ect 

interface 

return value S OK The operation was successful. 

E^INVALIDARG One of the arguments is invalid. 

E_UNEXPECTED An unexpected error happened. 



To establish a direct link between Hie tn-Place server and the container, the Server calls 
25 IQtelnPlace3Dsite:-GetWindowContert and stores it. then it caiis OelnPlaceViews:SetActive3DObject giving its inter- 
face to i0ielnPlaceAciive3DObject. so the Container can store its connection too. 

A more detailed in-place activation flow diagram, as illustrated in Fig. 35. is summarized below for convenience, 
although not necessary for one familiar with standard OLE. (Note: functions not described in the specification section 
are fully described in "Inside OLE 2" as described above): receiving !0leObject::DoVerb (or IOIe3DObject::DoVerb), the 
30 server calls the following: 

IOleClientSite; :QueryInterface for the IOielnPLaceSite interface, and 

35 JOlelnPlaceSite: ;0,uery Interface for the I01eInPlace3D5ite interface, 

and stores it- 

IDlelnPlaceSite: :CanInPlaceActivate, asking if the container supports 

In-place activation. 
4j} IDleInPlace3D£ite: : GetModelMatrix to get the ModelHatrix (outermost 

container to server) . 



45 



55 



22 



EP 0 723 250 A2 

This calls recurses until it reaches the outermost three-dimensional container. 

IOlelnPlaceEite: :OnInPlaceActivate to notify the container that the 

object is about to be activated. 
IOlelnPLaceSite: :OnUlActivatate to notify the container that the menus 

ar*? going to be merged. 
TOlelnPlaceSite: :GetWindouContext to return IOlelnPl aceFrame and 

IOlelnPlaceUIHindow interfaces. 
I01eInPiace3DSite; ;GetWindowContext to return the IOlelnPlaceViews 

interface (windows manager) . 

CreateMenu to create an empty menu. 

lOlelnPlaceFrame: : InaertMenue to ask the container to insert its menus . 
InaartMenus to insert its own menus. 

XOielnPlaceUIWindow: : SetActiveOb ject to give the container a pointer 

to its JOlelnPlaceActiveObject. 
roielnPlaceViews: : SetActive3Dob ject to give the container a pointer to its 

IDleInPlaceActive3DObjeot . 
IDlelnPlflceViewa: -. EnumlnPlaceViews to get the liat of container views. 
lOielnPlaceViews: : GetViewsContext to get view context for each view. 
lOlelnPlaceFrame: :SetHenu to set the composite frame menu on the 

container' s frame. 



£.3, IOIelnPiaceAc1ive3DObiect 

The IOIelnPlaceActive3DObject interface aitows the container to irform the In Place active object of any view 
changes, deletions or crealions. The l0le!nPlaceActive3DObject interlace is an extension o? the lOielnPlaceActiveOb- 
jeect interface and is implemented by three-dimensional containers supporting In Place Activation. 
!0leinPlaceActive3D0bject functions are used in the same programming context as the lOlelnPIaceActiveObject func- 
tions, adding the functionality of notifying the server of muftipie views, as described below. The 
l0lelnP!aceActive3DODject interface derives from IOIelnPlace\/!ews::SetActive3DObject as described above. 

Fig. 30 illustrates a iOleinPlaceActive3DObject imerface 1380 tor a user interface 1390. User interface 1390 
-to includes lOlelnPlaceActiveOSject interface 1400. IOtelnPlaceActive3DObject interface 13S0 includes a Onln- 
PlaceViewChange function 1410. an OnlnPlaceViewChange function 1420, and a OnlnPlaceViewDelete function 1430 
as will be described below. 
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The following is a description of the preferred embodiment of trie formal OelnPlaceActiveSDObject interface: 

interface I01eInPlaceActive3DO£>ject : lunknown { 
// * lUnknown methods * // 

HRESULT Querylnterface {REFIID riid, LPVOID FAR" ppvOb j ) ; 
ULONGAddRef ( ) ; 
ULONGRelease ( I ; 

// * lOlelnPlaceActiveObject methods * // 
// * I01eInPlaceActive3DObject methods * // 

HRESULT OnlnPlaceViewChange (HWND hwnd, LPXFOimthree-diroenaional 
pVtoW, I.pxFORMthree-dimensional 
pWtoV) ; 

HRSSUXT OnlnPUoeViewCreate {HWND hwnd); 
HRESULT OnlnPlaceViewDelete (HWND hwnd); 
} 



2-3-1- 

zs IQIein PiaceActi ve3 DObiect ::Onl nP laceVi ewGhanne 

Tho first I0Ie!nP!aceActive3DObject function OnlnPlaceViewChange is used when the outermost three-dimension 
container modifies one of its In Place views. An example is if the position of views 1020 and 1030 in Fig. 24 are 
switched. In response, the container calls OnlnPlaceViewChange which notrties the in Place server of the change in the 
30 transformation matrices between the positioning of the views in the container and the server. 

The following is a description of the preferred embodiment of the formal OnlnPlaceViewChange interface: 

IOlelnPlaceActiveiDobject : :onInPlaceViewChange 
3S HRESUI/T IOleInPlaceActive3DObject:;OnInPlaceVxewChange 

(HWND hwnd, LPXFORMthree-dimensional pVtoW, 
LPXFORMthree- dimensional pWtoV) 
Argument Type Description 
40 hwnd HWND Handle of the view modified. 

pVtoW LPXFORM3D ViewToWorld three-dimensional Matrix transformation 
(this is a 4x4 Matrix following OpenGL standard, it 
carries rotation, translation, scaling, shearing, and 
4S perspective information. 



SO 
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pWtoV LPXFORM3D WorldToview three-dimensional Matrix transformation 
(this is a 4x4 Matrix following OpenCL standard, it 
carries rotation, translation, scaling, shearing, and 
perspective information. 

return value S_OK The operation was successful 

E_OuTOFMEMORY The matrix cannot be allocated. 

E_INVALIEARG one of the arguments 1b invalid. 

E_UNEXPECTEO An unexpected error happened. 

The in-place server has to keep this information. One matrix (ViewToWorldJis used for locate purpose, the Olhei one 
(WorldToViaw] for display in dynamics. These two matrices are passed because they might carry perspective or projec- 
tion and can be singular, so one might not he deduced from the other one by inversion. 



|pielnPiaceActiy.e 3D0biect::0nlnPlaceVi&wChanQe 

The second IOielnPlaceActive3DGbject function OnlnPlaceViewCreate is used when the outermost three -dimen- 
sional container adds a new view of an object to the container. An example is if the container adds another view of 
object 1000 above position 1030. in Fig. 24. in response the container calls OnlnPSaceViewChange. which notifies the 
in Pface server of the new view. 

The following is a description of the preferred embodiment of the formal OnlnPlaceViewCreate interface: 

I01eInPlaceA.ctive3DObject : : OnlnPlaceViewCrcatc 

H RESULT IOLeInPlaceActiv*3BObject; : OnlnPlaceViewCreate 

(HWND hwnd) 

Notifies the In-Place Object that the outermost three-dimensional 
container just created a new in-place active window. 
Argument Type Description 

hwnd HWND Handle of the view created. 

return value s_OK The notification is received successfully 

£_INVAX-IDARG One of the arguments is invalid. 

^ UNEXPECTED An unexpected error happened. 



The in-place server then calls OelnPiaceViews: :GetViewContext to get the new display context and stores it. 
2.3.3. 

so IOi einPtaceActive3DObiect::OnfnPlaceViewDelete 

The third IO!elnP!aceAcSive3DObject function OnlnPlaceViewDelete is used when Ihe outermost three-dimension 
container deletes a view of an object to the container. For example, if view 101 0 of object 1000 in Fig. 24 is deleted, the 
container calls OnlnPlaceViewDelete and notifies the In Place server to stop displaying that view. 
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The following is a description of the preferred embodiment of the formal OninPlaceViewDelete interface: 

I01elnPlaceActive3DOb ject; : OninPlaceViewDelete 
HRESUT.T IoleInPlaceAccive3DObject: rOnlnPlaceviewDe lete 

(HWND hwnd) 

Notifies the Irs-Place Object that the outenooat three-dimensional 
container just deleted a view participating in the in~place activatic 
Argument Type Description 

hvmd hwnd Handle of the view deleted, 

return value S OK The delete notification is received 

succeaaf ully 

E_rnvALiDARG One of the arguments is invalid. 

E UNEXPECTED An unexpected error happened. 



so The in-place server then remove this view from its "active view list" and free the useless context. 
3. Interfaces Enabling Thre e-Dimensional Ob ject Interaction 

The new OLE interfaces as described herein allow three-dimensional objects to interact with each other in the con- 

ss tainer coordinate system. When applications combine three-dimensional objects in complicated relationships within a 
container/document, to interact properly, objects must make use of spatial information of surfaces in other objects. This 
"interoperability" between objects extends to enabling one object to "find" the "elements" making up another object. 
What is done with that information ts up to the user or server application. Interoperability further allows overlapping 
objeds to utilize each other's position and geometry during complicated, precise-relationship manipulations. A common 

so example involves the user wanting lo manipulate some geometric element relative to the geometry of some other object 
(or element in the container). 

Fig. 31 illustrates the lOlel ocate interface 1 440 for a user interface 1 450 of an object. User interface 1 450 includes 
an lOleltemComainer interface 1460 that is also available to OLE objects. OeltemContamer interface 1460 includes a 
function 1470 that when called returns a pointer to lOleLocate interface 1440 if the object can return spatial information. 

35 lOleLocate interface 1440 includes a PointLocate function 1480, a ShapeLocate function 1490, and an lOtellemCon- 
tainer function 1500 as will be described below. 

To use lOleLocate, the server must insure that function 1470 can return a pointer to the lOleLocate interface 1 460. 
Similarly, lOleLocate function 1 500 must also return a pointer to lOleftemContainer interface 1460 so that the container 
can take ad/antage of other SOleltemContainer functions such as EnumObjects and ParseDisplayName (not shown). If 

40 the server only supports location of the objecl itself and not "elements" of the object, then OeLocate need not be con- 
cerned with lOlettemContainer. 

The following is a description of the preferred embodiment of the formal lOleLocate interface and variable type def- 
initions; 
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interface IOleLocate : lUnknoi 
If * IDnknown methods ' 
HRESULT Quetylntetface 
UXONGAddRef ( ) ; 
ULONGRe lease < ) ; 
J J * IOleLocate method! 
~ PointLocate 



HRESULT ShapeLocate 



(REFI1D riid, LPVOID FAR* ppvObj ) f 



' * u 

{LPBORELINE pBoreLine, LPENUHMONIKJBR* 
ppEnurc-Moniker ) ; 

(i/PSHAFE pshape, lpenuumoniker- 

ppEnumManiker } ; 



typedef Btc-JCL tayBoteLine \ 

double tn_point[3J; 

double m_directi_on( 3 ] ; 

double m_front; 

double m back; 

double ro_radius; 

} BORELINE; 
typedef BORELIME FAR* LPBOREL IKE ; 



// Bc-reLine definition 
// Eye Point 

// Direction vector 
// Front curvilinear abscissa >= 0.0 

// Back curvilinear abscissa <= 
// Tolerance to locate > 0.0 



typedef enum tagSHAPETrPE { 
SHAPETYPE_INSIDE = 0, 
SHAPETiPEJDUTSIDE = I, 

SHAPETYPEOVERLAP = 2 

} SHAPETYPE; 



// Possible types of ahapes 
// Select the elements inside the polygon 
// select the elements outside the 
polygon 

// select elements overlapping either 
INSIDE or OUTSIDE 



typedef 

double* 
int 



tagShape { 



// Shape definit 
// List of point: 
// Number of poii 



defining the polygon 
:b in the list 



double m_direction( 3 ) ; // Direction vector {of shape walls) 
double m_front; // Front curvilinear abscissa >= 0.0 

double m_back; // Back curvilinear abscisea <= 0.0 

SHAPETYPE m_type; // type of shape described 



typedef SHAPE FAR* LPSHAPE; 



3J. IOleLocate; PointLpsas 

The first IOleLocate function PointLocate enables a server to obtain a list of "elements" in another object that inter- 
sect a user defined boreline m spaca. 

Fig. 32 is a flow diagram of one embodiment of trie process of locating elements in an object using the PointLocate 
function. 
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The user first defines a boreline within the container coordinate system (step 1520). Next, lOleLocate: PointLocate 
is called and the other servers respond to this function by determining what pieces of it (elements) intersect boreline 
(step 1 530). Elements that meet the criteria are returned as a list of monikers (step 1540). (Alternatively, the object can 
simply return all of its elements.) Once the list of monikers is returned, the server then calls the BindMoniker helper 
5 function or IMoniker::BindToOtoject (described in the appendices) to bind each moniker, i.e., convert each element into 
an individual object (step 1550). Each new object tnat intersects the defined boreline can then be used by the server 
for any purpose. 

Figs. 34a - 34c illustrate the use of the l01el_ocate::Pointl_ocate function. Fig. 34a includes a first Object 1590. a 
bolt, a second object 1600, a block with surface 1610 and 1620, and a borettne 1G30. Tig. 34b includes a first object 
to 1640 and a second object 1650. Fig. 34c includes a modified first object 1650, a bolt, and block 1600. Bolt 1 590 was 
created in a first software application and transferred into the container, which created block 1600. 

Withoul the lOieLocate::PointLocate function, bolt 1 590 and block 1 600 are simply within the container without any 
knowledge of other each other. With the lOleLocate;:PointLocate function, bolt 1590, for example, receives information 
regarding other objects in the container. As illustrated in Fig. 34a, rf the user wants to extend the length of bolt 1 590 until 
is it touches block 1600, the user first defines boreline 1630 along the axis of bolt 1590. The server then calls OeLo- 
cate::PointLocate. as disclosed in Fig. 32. As illustrated in Fig. 34a. boreline intersects with surfaces 1610 and 1620 of 
block 1600, thus the IOieLocate::PointLocate function returns monikers for these surfaces. As illustrated in Fig. 34b. 
each moniker is then converted into first object 1640 and second object 1650. Since the server now knows the coordi- 
nates o! first object 1640 and second object 1650, the user can exlend the length of bolt 1590 until modified bolt 1660 
a> touches block 1600, as illustrated in Fig. 34c. 

The following is a description of the preferred embodiment of the formal PointLocate interface: 

lOleLocate: : PointLocate 
S5 HRESULT lOleLocate:: PointLocate (LPSORELIHE pEoreLine, LPENUMWONIKER* 

ppEmnnMoniker ) 



Gets a list of all elements of an object that intersect with a point or a 
Argument Type Description 

pBoreLine LP5QRELINE Point + depth information to define a 

sphere or a cylinder used for the 
intersection criteria. This is a 
pointer to a boreline structure. 
ppEnumMoniker LPENUMMONIKER* Moniker enumerator. Each clement 

located is a moniker. 
S_0K The operation was successful 

Out of memory. 

One of the arguments is invalid. 
An unexpected error happened. 



return value 
E_0UTOFM£MORY 

E INVALIDARG 

E_UWEXFECT£D 



Return an enumerator of monikers. This moniker can be converted to a DataObject. 
&2 IQI Locate: ShspgLocgle 

The second lOleLocate function ShapeLocate allows a server to obtain a list of "elements" in another object that 
intersect to a user defined shape in space. 

Fig. 33 is a flow diagram of one embodiment of the process of locating elements in an object using the ShapeLo- 
cate function. 

The user first defines a shape within the container coordinate system (step 1570) Next, lOleLocate:ShapeLocate 
is called and the other servers respond to this function by determining what pieces of it (elements) intersect the boreline 
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(step 1 SSO) . Elements that meet the criteria are returned as a list of monikers (step 1 590). (Alternatively, the object can 
simply return all ot its elements.) Once the list of monikers is returned, the server then cads the BindMoniker helper 
function or IMoniker::BindToObject to bind each moniker, i.e., convert each element into an individual object (step 
1600). Each object that intersects the defined shape and can be used by the server for any purpose. In operation, the 
IOieLocate:;ShapeLacate (unction operates in the same manner as illustrated in Figs, 34a-34c. 
The following is a description of the preferred embodiment of the formal ShapeLocate interlace: 



lOleLocate: :ShapeLocate 
HRESULT lOleLocace : :ShapeLocat< 



Gets a li; 

Argument 

pSiiape 



all elements : 
Type 
LPSHAPE 



(lpshapc: pshape, lpenummoniker* 
ppEnumMoniker) 
.'Cting/contained by a shape. 

Shape defined by a set of points 
defining a polygon, a depth and an 
attribute specifying the position < 
the object relative to this shape. 



ppEnumMoniker LPEMUKHONIKER* 

return value S_OK 
E_OUTOFHEMORY 

E_UNEXPECTED 



Moniker enumerator. Each element 
located is a moniker. 
The operation was successful 
Out of memory . 

One of the arguments is invalid. 
An unexpected error happened. 



Return an enumerator of monikers. This moniker can be converted to a DataObjeet 

In the foregoing specification, the invention has been described with reference to a specific exemplary embodi- 
es ments thereof. Many changes, modifications, and additional extensions to OLE facilitating the transfer of three-dimen- 
sional specific information from an object created in a first software application to a second software application are 
readily envisioned and are included within other embodiments of the present invention. 

The specification and drawings are. accordingly, to be regarded in an illustrative rather than in a restrictive sense. 
It wii, however, be evident that various modifications and changes may be made thereunto without departing from me 
40 broader spirit and scope of the invention as set forth in the claims. 



1 . In a computer system including a display, a first software application, and a second software application, a method 
for manipulating a first three<itmensional object, comprising the steps of: 

creating a model of the first three-dimensional object with 'the first software application, the first software 
application having a first three-dimensional coordinate system: 

storing the mode! of the first three-dimensional object in a model format; 

retrieving the model of the first three-dimensional object in the model format into a second software applica- 
tion, the second software application having a second coordinate system; and 

manipulating a view of the model of the first three-dimensional object with the second software application 
and within the second coordinate system. 

2. The method of claim 1 , wherein 

the second coordinate system is a second three-dimensional coordinate system, 

3. The method of claim 2, further comprising the steps of; 

creating a model of a second three-dimensional object with the second software application and within the 
second coordinate system; and 
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manipulating the model of the second three-dimensional object wilh the second software application utilizing 
the model of the first three-dimensional object. 

4. The method of claim 3, further comprising the Step of: 

s manipulating the view of the model of the first three-dimensional object with the second software application 

utilizing the mode! of the second three-dimensional object. 

5. The method of claim 1 , wherein; 

said second coordinate system is a two-dimensional coordinate system. 

6. The method of claim 5. further comprising the steps of- 

creating a model of a two-dimensional object with the second software application and within the second 
coordinate system; and 

manipulating the model of the two-dimensional object with the second software application utilizing the 
15 model of the first three-dimensional Object. 

7. The metlicd of claim 5, further comprising the step of: 

manipulating the view of the model of the first three-dimensional object with the second software application 
utilizing the modal of the second three-dimensional object 

8. In a computer system including a display, a first software application, and a second software application, a method 
for manipulating a two-dimensional object, comprising the steps of: 

creating a model of the two-dimensional object with the first software application, the first software applica- 
tion having a two-dimensional coordinate system; 
2= storing the model of the Iwo-dimensional object in a model format; 

retrieving the model of the two-dimensional object in the model format into a second software application, 
the second software application having a three-dimensional coordinate system; and 

manipulating a view of the model of 1he two-dimensional object with the second software application and 
within the three-dimensional coordinate system. 

9. The method of claim 3. furthei comprising the steps of; 

creating a model of a three-dimensional object with the second software application and within the three- 
dimensional coordinate system; and 

manipulating the model of the three-dimensional object with the second software application utilizing the 
35 model of the two-dimensional object. 

1 0. The method of claim 9, further comprising the step of: 

manipulating the view of the model of the three-dimensional object with the second software application uti- 
lizing the model of the two-dimensional object. 

to 

11. The method of anyone of the claims 2 to 4. wherein the retrieving step comprises the steps of: 

calculating an attachment matrix between the first three-dimensional coordinate system and the second 
three-dimensional coordinate system; 

transforming extent coordinates for the first three-dimensional object in [he first three-dimensional coordi- 
« nate system with the attachment matrix into extent coordinates for the first three-dimensional object in the second 

three-dimensional coordinate system; and 

returning the extent coordinates for ihe first three-dimensional object in the second three-dimensional coor- 
dinate system to the second software application. 

so 1 2. The method of anyone of the claims 8 to 1 0. wherein the retrieving step comprises the steps of: 

calculating an attachment matrix between the two-dimensional coordinate system and the three-dimen- 
sional coordinate system; 

transforming extent coordinates for the two-dimensional object in the two-dimensional coordinate system 
with the attachment matrix into extent coordinates for the two-dimensional object in the threedimensional coordi- 
55 nate system; and 

returning the extent coordinates for the twod mensional object in ihe three-dimensional coordinate system 
to the second software application. 
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f 3. The method of anyone of the claims 5 to 7, wherein me retrieving step comprises the steps of: 

retrieving a predefined attachment matrix between the three-dimensional coordinate system' and the two- 
dimensional coordinate system: 

passing the predefined attachment matrix to the model of the first three-dimensional object; and 
returning a predefined view of the model of the first three-dimensional object to the second software appli- 
cation in response to fhe predefined attachment matrix. 

1 4. The method of anyone of the claims 5 1o 7, further comprising the steps of: 

retrieving an attachment matrix between the three-dimensional coordinate system and fhe two-dimensional 

coordinate system; 

defining a modilied attachment matrix between the three-dimensional coordinate system and the two- 
dimensional coordinate system, 

passing the modified attachment matrix to the model of the first three-dimensional object, and 
returning a modified view of the model of the first three-dimensional object to the second software applica- 
tion in response to the modified attachment matrix. 

1 5. The method of anyone of the claims 2 to 4. further comprising the steps of: 

calculating an attachment matrix between the first three-dimensional coordinate system and the second 
three-dimensional coordinate system; 

calculating a transformation matrix between the second three-dimensional coordinate system and a two- 
dimensional coordinate system of the display; and 

displaying a view of the model of the first three-dimensional object on the display in response to the attach- 
ment matrix and the transformation matrix. 

1 6. The method of anyone of the claims 2 to 4, 11 . 15. wherein the manipulating step comprises fhe steps of- 

calculating an attachment matrix between the first three-dimensional coordinate system and the second 
three-dimensional coordinate system; 

modifying the second three-dimensional coordinate system into a modified three^imensiona! coordinate 
system with the second software application; and 

calculating a modified attachment matrix between the first three-dimensional coordinate system and the 
modified three-dimensional coordinate system, and 

passing the modified attachment matrix to the first software application and the model of the first three- 
dimensional object. 

17. In a computer system including a display, a first software application, and a second software application, a method 
for manipulating a first three-dimensional object, comprising the steps of: 

creating a model of the first three-dimensional object with the first software application, the first software 
application having a first three-dimensional coordinate system; 

storing the model ot the first three-dimensional object in a model format; 

retrieving the model of the first three-dimensional object in the model lormat into a second software applica- 
tion, the second software application having a second three-dimensional coordinate system; 
activating the first software application from within the second software application, and 
manipulating the model ol the first three-dimensional object with the first software application within the first 
three-dimensional coordinate system. 

18. The method of claim 17, wherein the activating step comprises the steps of: 

calculating an attachment matrix between the first three-dimensional coordinate system and the second 
three-dimensional coordinate system; and 

passing the attachment matrix to the first software application. 

19. The method of claim 17. further comprising the steps of: 

calculating an attachment malrix between the first three-dimensional coordinate system and the second 
three-dimensional coordinate system; 

calculating a transformation matrix between the second three-dimensional coordinate system and a two- 
dimensional coordinate system of the display; 

passing the attachment matrix and the transformation matrix lo the first software application; and 

returning a pointer to the model of the first three-dimensional object to the second software application. 
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20. The method of claim 1 7, further comprising the steps of: 

calculating an attachment matrix between the first three-dimensional coordinate system and the second 
three-dimensional coordinate system; 
selecting a first display view ; 

calculating a transformation matrix between the second three-dimensional coordinate system and a two- 
dimensional coordinate system of the first display view; and 

displaying a first viewo! the firs! three-dimensiona! object with the first software application to the display, in 
response to the attachment matrix and the transformation matrix 



jo 21. The method of claim 20. further comprising the steps of: 

creating a model of a second three-dimensional object with the second software application and within the 
second coordinate system; and 

displaying a first viewo! the second three-dimensional object to the display, in response to the transforma- 
tion matrix. 

22. The method of claim 20, further comprising Ihe steps of: 

selecting a second display view ; 

calculating a transformation matrix between the second three-dimensional coordinate system and a two- 
dimensional cooidinate system of the second display view: and 
^ displaying a second view of the first three-dimensional object with the first software application to the display, 

in response to the attachment matrix and the second transformation matrix. 

23. The method of claim 21 , further comprising the steps of: 

selecting a second display view; 
2= calculating a transformation matrix between the second three-dimensional coordinate system and a two- 

dimensional coordinate system of the second display view; 

displaying a second view of the first three-dimensional object with the first software application to the display, 
in response to the attachment matrix and the second transformation matrix; and 

displaying a second view of the second three-dimensional object to the display, in response to the attach- 
30 ment matrix and the second transformation matrix. 

24. The method Of Claim 22. further comprising the steps of: 

selecting the second display view; and 

removing the second view of the first three-dimensional object with the first software application from the dis- 
ss play. 



25. The method of claim 22, further comprising the steps ot: 

selecting the second diaplay view; 

removing the second view of the first three-dimensional object with the first software application fiom the dis- 
40 play; and 

removing the second view of the second three-dimensional object from the display. 

26. The method of claim 24 or 25, further comprising the step of: 

enumerating the first display view and the second display view. 

45 

27. The method of anyone of the claims 20 to 26. further comprising the steps of: 

changing the first display view to a second display view; 

calculating a second transformation matrix between the second three-dimensional coordinate system and a 
two-dimensional coordinate system of the second display view; and 
50 displaying a changed first view d( the first three-dimensional object with the first software application to the 

display, in response to the attachment matrix and the second transformation matrix. 



28. The method of anyone of the claims 2 to 4. 11. 15, 16, further comprising the steps of . 

locating a point in the second three-dimensional coordinate system; 

locating an element in the model of the fist three-dimensional object that intersects with the point; and 
returning a moniker for the element to the second software application. 

29. The method of anyone of the claims 2 to 4, 11, 15, 16, further comprising the steps of: 

locating a polygon in the second three-dimensional coordinate system; 
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locating an element in She model of the first three-dimensional object that intersects with the polygon: and 
returning a moniker for trie element to the second software application. 

30. The method of claim 28 or 29, further comprising the step of: 

creating a model of the dement in response to the moniker for the element. 



NSOCCID;<EP O723SS0A2 I 



EP 0 723 250 A2 





Tan 


Feb 


Mar 


R 


1 


1 


2 




3 


5 


8 


E 


13 


21 


34 


W 


55 


89 


99 



The Patent and Trademark Office shall 
continue as an office in the Department of 
Commerce, where records, books, drawings, 
specifications, and other papers and things 
pertaining to 



Feb 



1 



patents and to 
trademark 
registrations shall 
be kept and 
preserved, except 
as otherwise 
provided by law. 



1 17 Fi 9- 1 




v ' J 

Fig. 2 

34 




Fig. 3 



EP 0 723 250 A2 




Fig. 4 



36 



EP 0 723 250 A2 




EP 0 723 250 A2 




Fig. 6 



EP 0 723 250 A2 



J 



66 67 



Disk 
Drive 

ir 



Digitizing 
Table! 



Keyboard Mouse 



Fig. 7 



EP 0 723 250 A2 



IOIe3DObject 



IOIeObject 



IOie3DObject 
IOIeObject 



Queryinterface 

IOIeObject 

Get3DExtent 

SetDefauitView 

SetView 



rOIe3DObjert 



3D container gets pointer 
to 101e3DObject interface. 

Query 
rUnkno wn ::IO!e3DObject 



78 

ao 



34 
85 



Fig. 8 



Get pointer to IOIeObject 
interface. 
Query 
IUnknown::IOIeObject 



Manipulate object as a 3D 
object. 




no 


Manipulate object as a 2D 




object. 



Fig. 9 



40 



EP 0 723 250 A2 




Fig. 10a 



Fig. 10b 



Calculate attachment 
matrix between 3D Object 
and 3D Container 



Get extent of 3D object. 
IO!e3DObject::3DGetExtent 



Calculate extent of 3D 
object in the Container 
Coordinate System 



Calculate attachment 
matrix between 2D Object 
and 3D container 



Get extent of 2D object. 
IOleObject-GetExtent 



Calculate extent of 2D 
object in the Container 
Coordinate System 



Fig. 11a 



Fig. 11b 



41 



EP 0 723 250 A2 




42 



( 



EP 0 723 250 A2 




2D Container gets pointer 
to IOie3DObject interface. 

Query 
IUnknown::I01e3DObject 




Get pointer to IOleObject 
interface. 
Query 
IUnknown::I01eObject 



2D Container retrieves 2D 
view of 3D object 



2D Container retrieves 2D 
view of 2D object 



Fig. 13 



Calculate a transformation 

matrix between the 3D 
server coordinate system 
and the display 



Retrieve a default 2D view 
of the 3D object. 

IOIe3DObjecfc: 
GetDefaultView 



Display default v 



Fig. 14 



43 

(NSDOCID: <EP CilVXXfM I > 



EP 0 723 250 A2 




The Patent and Trademark Office shall continue 

. as an office in the 

Department 

■ * of Commerce, where 

records, books, drawings, 
specifications, and other papers 
and things pertaining to 

1 patents and to trademark 

registrations shall be kept 
and preserved, except as 



otherwise provided by law. 



Fig. 15 



EP 0 723 250 A2 



490 



Calculate a transformation 
matrix between the 3D 
server coordinate system 
and the display 



500 



Set and retrieve a view of 
the 3D object, 
I01e3DObject::SetView 



510 



Display selected view of 
the 3D object 



Fig. 16 



EP 0 723 250 A2 



530 



540 



The Patent and Trademark Office shall continue 




^^"^-v. as an office in the 




^ s "\_ Department 






.^""j of Commerce, where 






^>«^^^ I records, books, 






I drawings, 






^"«s|^*j specifications, and other 






JL papers and things 






pertaining to patents 






1 and to trademark 






\ registrations shall be 




I kept and preserved, 




^^X^ except as otherwise 


provided by law. 



Fig. 17 



QlUn: 



a 



IViewGLObject 



IViewObject 



P 0 723 250 A2 



IViewGLObject 
IViewObject 



Query Interface 

IViewObject 

Draw 



IViewGLObject 
Draw 



590 
600 



630 
640 



610 
620 



3D Container gets pointer to 
IViewGLObject interface. 
lUnknown:: 
IViewGLOBject 



Fig. 18 



3D Container gets pointer 
to the IViewObject 
interface. 
IUnknown::IViewObject 




Render 3D Object. 
IViewGLObject: Draw 



no 


Draw Object. 




IViewObject:: Draw 


700 






Fig. 19 



47 



EP 0 723 250 A2 



Calculate transformation 
matrix between 3D 
Container coordinate 
system and display 



Define clipping planes 




740 



Draw 3D Object. 
IViewGLobject::Draw 



Fig. 20 



48 



EP 0 723 250 A2 



QlUni 



leInFlace3DObject 



a 



IOlelnPlaceObject 



IOleInPlace3D0bject 
IOlelnPlaceObject 



Query Interface 

IOlelnPlaceObject 

OnModelMatrixChange 



IO!e3DInPIaceObject 



Get pointer to 
I01eInPlace3DObject 

interface. 
Query lUnknown:: 
IOIeInPlace3DObject 



Get pointer to 
IOlelnPlaceObject 

interface. 
Query lUnknown:: 
IOlelnPlaceObject 




770 
800 
810 



830 
840 



Fig. 21 



In Place 2D server can 
InPlace activate 



In Place 3D server can 
InPlace activate 



Fig. 22 



49 



EP 0 723 250 A2 



920 



Calculate attachment 
matrix between 3D server 
and 3D container 
coordinate systems 



930 



Modify 3D container 
coordinate system 



940 



Calculate modified 
attachment matrix between 
3D server and 3D container 

coordinate systems 



950 

J 

Notify 3D server of 
modified attachment 

matrix 
I01eInPlace3DObjecn: 
OnModelMatrixChange 



Fig. 23 



50 



EP 0 723 250 A2 




EP 0 723 250 A2 



a 



IO!eInPIace3DSite 



IOieInPlace3DSite 
IOlelnPlaceSite . 



■a 



IOIelnFlaceSite 



Query Interface 
IOIelnPlaceSite 
GetModelMatrix 
GetWindowContext 



IOLeInPIace3DSite 
GetWindowContext 



3D container gets pointer 
to IOieInPlace3DSite 

interface. 
Query IUnknown:: 
I01eInPlace3DSite 



Fig. 25 



Get pointer to lOlelnPlace 
IOIelnPlaceSite interface. 
Query IUnknown:: 
IOIelnPlaceSite 




3D Object can be In Place 
active in multiple views 



no 


3D object cannot be InPlace 




active in multiple views 



Fig. 26 



EP 0 723 250 A2 





fan 


Feb 


Mar 


N 


1 


1 


2 


S 


3 


5 


8 


E 


13 


21 


34 


W 


55 


89 


99 



1220 



The Patent and Trademark Office shall 
continue as an office in the Department of 
Commerce, where records, book*, drawings, 
specifications, and other papers and things 





lan 


teb 


Mar 


N 


1 


1 


2 




3 


5 


8 




13 


21 


34 


w 


55 


89 


99 



patents and to 
trademark 
registrations shall 
be kept and 
preserved, except 
as otherwise 
provided by law. 




Fig. 27 



S3 



EP 0 723 250 A2 



1250 

Determine attachment 

matrix between the 3D 
Server's and the adjacent 
3D Container's Coordinate 
systems 




Pass attachment matrix 
between the 3D Server and 
the top most container's 
coordinate system to the 
3D Server 



Determine new attachment 
matrix between preceeding 
two conatiner's coordinate 
systems. Append to 
attachment matrix. 



Fig. 28 



IOIemPlace Views 



lOIelnPlaceUTWindow 

O 



Query Interface 
EnumlnPlaceViews 
GetViewContext 
SetActive3DObjecr 



SetActiveObject 



Fig. 29 



54 



EP 0 723 250 A2 



IOlelnPJaceActi ve3 DObjecb^" 



O 



IOlelnPlaceActiveObject 



O 



OninPlacfiViewChange 
OnlnPlaceViewCreate 
OnlnPlaceViewDelete 



Fig. 30 



1440 Q lOIeLocate 



IOleltemContainer 

PointLocate 

ShapeLocate 



1450 

1500 
1480 
1490 



IOleltemContainer 



IOleLocate Interface 



Fig. 31 



55 



EP 0 723 250 A2 



1520 



Define Boreline in the 3D 
Coordinate system 



Determine elements 
intersecting boreline. 
IO!eLocate:;PointLocate 




Return list of monikers for 






intersecting elements 






i 


1550 




Convert each moniker into 
an object. Bind moniker. 






1570 


Fig. 32 



Define an object in the 3D 
Coordinate system 



ir 1 



Determine elements 
intersecting the object. 
IOleDocate-ShapeLocate 



Return list of monikers for 
intersecting elements 



1600 



Convert each moniker into 
an object Bind moniker. 



Fig. 33 



56 




57 



EP 0 723 250 A2 



Get pointer to 
lOlelnPlaceSite methods 
lOIeCl ientSi te: r 
Querylnterface. 




Fig. 35 








Get pointer to 
I01eInPlace3DSite methods 
lOlelnPlaceSite:: 








Create an empty menu 


Querylnterface 












CpRtSmex supports 
^--^In-Flace activationr^-^ 
< \IO!eInPlaceSite:: 

C3nIr^laceActi3«rte 












Ask container to insert the 
container's menus 
IOlelnPIaceFrame:: 
Inserth/lenus 


Get Container to Server 
mapping. 
I01eInPlace3 DSite: : 
GetModeiMatrix 












Insert empty menus 


4- 






Notify container object is 
about to be activated. 
lOlelnPlaceSite:: 
OnlnPlaceActivate 






+ 






Give container pointer to 
the active in-place object. 
IOlelnPlaceViews:: 

£/\Ctl V c J U KJ E? jcCI 






Notify container menus 
will be merged. 
lOlelnPlaceSite:: 
OnUIActivate 












Get a list of views in the 
container. 
IOlelnPlaceViews: : 
EnurnlnPlaceViews 


Return IOlelnPIaceFrame 






+ 


and IOlelnPlaceUIWindow 
interfaces. 
lOlelnPlaceSite:: 
Getwindowcontent 






Get view context for each 
view. 
IOlelnPlaceViews: : 
GetViewsContext 






t 


Establish handshaking. 
Return IOLelnPIaceViews 
interface. 
I01eInPlace3DSite:: 
GetWindowContext 






Set the composite frame 
menu on the container's 
frame. 
IOlelnPIaceFrame: : 
SetMenu 





Europaisches Pateniamt 
European Patent Office 
Office europeen des brevets (11) EP 0 723 250 A3 

EUROPEAN PATENT APPLICATION 

(51) ml a. 6 : G06T 17/00 



) Date of publication A3: 
16.04.1997 Bulletin 1997/16 



{21} Application number: 96100765.5 
(22) Date of filing: 19.01 .1996 



(84) Designated Contracting States: 


- Stubbs, Cameron M. 


DE FR GB IT ML 


Decatur, Alabama 35601 (US) 


(30) Priority: 23.01.1995 US 378251 


• Payannet, Dominique J. 
Madison, Alabama 35758 (US) 


(71 ) Applicant: Intergraph Corporation 
Huntsville, Alabama 35824 (US) 


• Patience, Robert 
Huntsville, Alabama 35801 (US) 


(72) Inventors: 

• Fortenbery, Marl* 
Fayettevifle, Tennessee 37334 (US) 


(74) Representative: Sparing - Rohi - Henseler 
Patentanwalte 
Rethelstrasse 123 
40237 Dusseldorf(DE) 



(54) Oie for design and modeling 

(57) A method for manipulating a first three-dimen- 
sional object, in a computer system including a display, 
a first software application, and a second software 
application. The present method includes the step of 
creating a model of the first three-dimensional object 
with the first software application, which has a first 
three-dimensional coordinate system. A step Of Storing 
the model of the first three-dimensional object in a 
model format is also included. The present method fur- 
ther includes the step retrieving the model of the first 
three-dimensional object in the model format into a sec- 
ond software application, the second software applica- 
tion having a second coordinate system. The present 
method also includes the step of manipulating a view of 
the model of the first Jhree-dtmensional object with the 
second software application and within the second 
coordinate system. 



CO 

< 




a 

LU 



■ - h I it 



EP 0 723 250 A3 



4> 



EUROPEAN SEARCH REPORT 



DOCUMENTS CONSIDERED TO BE RELEVANT 



TRANSACTIONS OF THE INSTITUTE OF 
ELECTRONICS, INFORMATION AND COMMUNICATION 
ENGINEERS OF JAPAN, 
vol. E70, no. 12, 1 December 1987, 
pages 1220-1228, XPG00471568 
MEKHABUNCHAK1J K ET AL: "INTERACTIVE 
SOLID DESIGN THROUGH 2D REPRESENTATIONS" 

page 1223, right-hand column, line 27 - 
page 1225, right-hand column, line 25 * 

COMPUTERS AND GRAPHICS, 

vol. 12, no. 1, 1 January 1988, 

pages 115-123, XP000I42149 

SHEU P C Y: "OBJECT-ORIENTED GRAPHICS 

KNOWLEDGE BASES*" 

* page 118, left-hand column, line 19 - 
page 122, line 2 * 

S 1 6SNALL PC, 

vol. 19, no. 2, 1 November 1993, 

pages 10- L6, XPO00415O29 

KRELL M: "A GRAPHICS PACKAGE FOR 

PRODUCING THREE-DIMENSIONAL HIERARCHICAL 

GRAPHICS ON PERSONAL COMPUTERS" 



SKAItCMCU (ln<.a.t| 



2 



